test(ui): poll for the copy failure state instead of a fixed tick budget - #3476

code-block.test.tsx › exposes failed copy feedback to assistive technology failed once in CI on #3474 — a branch that changes one line of CSP caching and no React code — and passed on re-run.

The race. settle spends a fixed budget of one microtask and one macrotask:

await Promise.resolve();
await new Promise((resolve) => setTimeout(resolve, 0));
flushSync(() => {});

That covers the success path, where the clipboard promise resolves and React re-renders. The failure path is longer: a rejected clipboard.writeText falls back to execCommand, and only once that returns false is the failed state set. On a loaded machine the assertion can run against the pre-failure render. It explains the shape of the flake exactly — only the two failure-path tests are exposed, and the success-path ones never flake.

The change. Both failure-path tests poll for the state they are actually about instead of guessing a tick count. The helper throws a named timeout, so a genuine regression still fails loudly rather than being waited out — I checked that by pointing the predicate at a sentinel that is never true and confirming it reports Timed out waiting for the copy control to report failure rather than passing.

What I cannot claim. I could not reproduce the flake locally: not in isolation (5/5 green), not with the whole ui/ directory in one process, not under --coverage, and not on a pristine origin/main worktree. So this removes a race that is visible in the code, not one I was able to observe. If it recurs, the timeout message will now say which condition was never reached, which is more than the previous failure gave us.

Separate from #3474 on purpose — an unrelated test-harness change does not belong in a one-line behavioural fix.

Summary by CodeRabbit

• Tests
  • Improved clipboard failure test reliability by waiting for asynchronous state updates.
  • Added timeout handling with clearer error feedback when expected updates do not occur.